WEBVTT 00:00.000 --> 00:14.240 This is Hacker Public Radio Episode 3,937 for Tuesday the 5th of September 2023. 00:14.240 --> 00:18.920 Today's show is entitled, Adventures in Py-Hole. 00:18.920 --> 00:24.360 It is the first show by new host noodles and is about 8 minutes long. 00:24.360 --> 00:26.960 It carries a clean flag. 00:26.960 --> 00:41.320 The summary is noodles recounts their experience getting a Py-Hole server. 00:41.320 --> 00:43.520 Hello listeners of Hacker Public Radio. 00:43.520 --> 00:48.600 I'm Nate, also known as Noodles, which is probably the name I'll put in the title as my host 00:48.600 --> 00:50.600 name. 00:50.600 --> 00:55.720 I know Hacker Public Radio is constantly asking for contributors, so I figured I'd 00:55.720 --> 00:58.760 start and contribute my own. 00:58.760 --> 01:03.080 I'm going to put this in the Emergency Q, so I figure not much of this will change 01:03.080 --> 01:09.240 over time, especially since it's just a recount of exactly what my experience in this was, 01:09.240 --> 01:11.880 but yeah, I hope you guys enjoy. 01:11.880 --> 01:17.720 So this is titled, Adventures in Py-Hole, and pretty much just in aftermath story, I've already 01:17.720 --> 01:22.400 done the setup for the Py-Hole, and I wrote it down after I set up the Py-Hole. 01:22.400 --> 01:27.240 So if I'm missing a few details, but you'll get the general list of how this went down. 01:27.240 --> 01:29.400 So what exactly is Py-Hole first off? 01:29.400 --> 01:35.480 Well, it's a DNS and DHCP server that allows for easy network side ad blocking along 01:35.480 --> 01:38.480 with the nice customizations of being that. 01:38.480 --> 01:44.400 A DNS server is kind of the server that you're a computer might ask, so if it asks, 01:44.400 --> 01:51.040 hey, what's google.com that DNS server will be churn the IP address of google.com. 01:51.040 --> 01:58.720 And a DHCP server is the server that gives out the IP addresses on your network. 01:58.720 --> 02:02.920 So the first step here is to actually get it running. 02:02.920 --> 02:08.440 And I did this using Docker Compose on my NAS, which even though I call it NAS, it's 02:08.440 --> 02:12.800 really my centralized server, that's just kind of what I call it. 02:12.800 --> 02:17.280 After a quick copy and paste from the Py-Hole's read me, I was pretty much up and running. 02:17.280 --> 02:22.240 I set up a singular system and use this as a DNS server and after that, I figured 02:22.240 --> 02:25.200 I was setting ready to go. 02:25.200 --> 02:27.040 But I wasn't quite satisfied there. 02:27.040 --> 02:31.200 I wanted automatic DNS setting for any device that connects to my network. 02:31.200 --> 02:33.560 Of course, I could just set the DNS upstream. 02:33.560 --> 02:41.680 I used open WRT router, so I could just set the DNS server in there, but not good enough 02:41.680 --> 02:42.680 for me. 02:42.680 --> 02:46.920 This means it'll be missing out on automatic per client information since when setting 02:46.920 --> 02:53.040 up a DNS server for your open WRT, it only sets itself to forward any DNS requests 02:53.040 --> 02:57.800 up to this DNS server, which means from Py-Hole's perspective, all the requests are coming 02:57.800 --> 03:02.680 from the router and nowhere else, and I wanted per client information. 03:02.680 --> 03:05.960 The solution here is to set up Py-Hole as a DHCP server. 03:05.960 --> 03:10.640 Keep in mind, I'm not giving it a tutorial or anything, so let's just go through what I 03:10.640 --> 03:12.360 did first. 03:12.360 --> 03:15.800 The first step was to turn on the DHCP server in Py-Hole. 03:15.800 --> 03:18.800 This was pretty easy, just a checkbox and click save. 03:18.800 --> 03:19.800 Awesome. 03:19.800 --> 03:26.640 I disabled the DHCP server in open WRT, and it was all set. 03:26.640 --> 03:31.920 A few restarting of some network devices later, like my phone and my laptop that I was using 03:31.920 --> 03:35.760 to set this up and they all automatically connected to the Py-Hole server, worked like 03:35.760 --> 03:40.000 a charm, they got IP addresses from it and everything else like that. 03:40.000 --> 03:42.120 Next up, I set up tail scale. 03:42.200 --> 03:46.760 I use head scale, which is kind of like the server side of tail scale, but one that you 03:46.760 --> 03:48.560 can host yourself. 03:48.560 --> 03:52.400 But the setup is pretty much exactly the same as if you were using tail scales, you 03:52.400 --> 03:53.400 why. 03:53.400 --> 03:59.200 I set in the config to override the local DNS, set the name server to the tail scale IP address 03:59.200 --> 04:02.200 of the server, and turn on magic DNS. 04:02.200 --> 04:03.680 Voila. 04:03.680 --> 04:08.480 Now to restarting the tail scale nodes, and make sure that on the server you set it not 04:08.480 --> 04:10.560 to accept the DNS from tail scale. 04:10.560 --> 04:14.320 If you don't do that, you'll get an endless loop of trying to use itself as a DNS 04:14.320 --> 04:15.320 server. 04:15.320 --> 04:16.320 It's just no good. 04:16.320 --> 04:17.320 All right. 04:17.320 --> 04:18.600 And after that, it's all set. 04:18.600 --> 04:21.760 I checked the dashboard and it's already blocking DNS requests. 04:21.760 --> 04:24.440 I can see all my tail scale devices in there. 04:24.440 --> 04:25.440 Perfect. 04:25.440 --> 04:26.440 Awesome. 04:26.440 --> 04:28.160 And I made a bit of a whip-sease. 04:28.160 --> 04:33.000 It was fine and great, but what I went to reboot my server, which I do weekly, something 04:33.000 --> 04:34.240 bad happened. 04:34.240 --> 04:36.560 The interface for the server didn't come up. 04:36.560 --> 04:41.800 The problem is that it's the DHCP server from a network, so without that networking, the 04:41.800 --> 04:43.320 network was dead in the water. 04:43.320 --> 04:44.960 It can't give out IP addresses. 04:44.960 --> 04:46.760 What's going on? 04:46.760 --> 04:50.900 I go ahead and access my server directly, no matter how hard I try, I cannot connect 04:50.900 --> 04:51.900 to the interface. 04:51.900 --> 04:52.900 What's the big deal? 04:52.900 --> 04:56.400 Well, this is actually pretty simple, and a question popped away ahead that got me 04:56.400 --> 04:57.400 there. 04:57.400 --> 05:00.560 How does the server even get its IP address? 05:00.560 --> 05:04.440 When I set up Python, it was just using the IP address that the router had given 05:04.440 --> 05:07.240 it earlier, which was more than happy to use. 05:07.240 --> 05:12.240 But the moment the router didn't have a DHCP server, the NAS had no way to get its own 05:12.240 --> 05:13.240 IP address. 05:13.240 --> 05:15.480 So, what's the answer here? 05:15.480 --> 05:17.400 Well, it's actually pretty simple. 05:17.400 --> 05:19.960 Just give the server a static IP. 05:19.960 --> 05:27.200 Make sure you set a static lease in the DHCP server of Python, and then I use network manager. 05:27.200 --> 05:34.360 You just set a quick static IP, and make sure it's DNS points to local host. 05:34.360 --> 05:36.160 And then everything is done. 05:36.160 --> 05:37.920 It worked like a charm. 05:37.920 --> 05:44.840 All right, crisis-averted, just a missing networking knowledge, happens to the best of us. 05:44.840 --> 05:47.240 So what's next up on the list? 05:47.240 --> 05:53.360 The default AdList is kind of small, let's go see if we could find some new AdLists. 05:53.360 --> 05:56.440 Apparently, this is a little bit more difficult than you'd think. 05:56.440 --> 06:01.560 A quick search on duck.go only came up with an equivalent search on GitHub. 06:01.560 --> 06:03.200 Not very useful. 06:03.200 --> 06:07.840 I have no idea the trustworthiness and stability of these AdLists. 06:07.840 --> 06:13.560 So another search leads to a Reddit article, and that leads to a different list. 06:13.560 --> 06:14.560 Awesome. 06:14.560 --> 06:16.080 An AdList list. 06:16.080 --> 06:21.200 This is FireballFireBog.net, and it's exactly what I needed. 06:21.200 --> 06:24.680 I went ahead and looked into these lists and added a few of them. 06:24.680 --> 06:25.680 Perfect. 06:25.680 --> 06:29.680 FireBog automatically sorts them by most stable to lease stable. 06:29.680 --> 06:34.080 So most likely it'll work versus a little bit more aggressive, but might break things 06:34.080 --> 06:35.800 in the process. 06:35.800 --> 06:38.960 All right, and the fifth step is maintenance. 06:38.960 --> 06:42.400 So what exactly do I do for maintenance of this server? 06:42.400 --> 06:47.680 Well, I used Docker Compose Pool, and then I used Docker Compose Up. 06:47.680 --> 06:50.760 Of course, this isn't always it. 06:50.760 --> 06:56.480 I use an AB update scheme, so I'll actually copy the container over to a different container, 06:56.480 --> 06:58.920 update that, run it, and if that doesn't work, 06:58.920 --> 07:04.080 I also, I still have that old container that I can go back to, but you still get the idea. 07:04.080 --> 07:09.600 Update your taken care of automatically by this, and just keep the server up as long as possible 07:09.600 --> 07:12.680 since this is what runs your DHCP server. 07:12.680 --> 07:16.840 I don't know, of course, I wasn't happy with just that. 07:16.840 --> 07:23.160 I wanted to move it off of my main NAS, there are a few reasons why I wanted to do that. 07:23.160 --> 07:28.120 For first, I liked having the magic DNS from tail scale on my server. 07:28.120 --> 07:32.800 I like being able to access my other computers using the server as kind of like a jump 07:32.800 --> 07:34.800 post. 07:34.800 --> 07:39.560 Number two, I wanted to have a computer that I can have on all the time. 07:39.560 --> 07:45.080 If I needed to update my server, it ends up taking down my whole network, so, or maybe 07:45.080 --> 07:50.120 some other problem happens with my server, and then I'm dead in the water for my network. 07:50.120 --> 07:53.480 And I don't like that dependency there. 07:53.480 --> 07:57.040 What I did was I ran it on a Raspberry Pi 3. 07:57.040 --> 08:00.520 I used Arch Linux ARM, which is what I already run on my NAS. 08:00.520 --> 08:02.720 I used Arch Linux on there. 08:02.720 --> 08:04.880 And then I just followed the same exact steps for that. 08:04.880 --> 08:10.600 I made sure that I set it as a static IP and just set it up on there, and it works wonderfully. 08:10.600 --> 08:15.360 I don't have to worry about whether, oh, I need to reboot my server because I changed 08:15.360 --> 08:17.320 this configuration file. 08:17.320 --> 08:19.240 I don't need to worry about that anymore. 08:19.240 --> 08:22.000 It's on a different computer now. 08:22.000 --> 08:25.000 So yeah, that's mainly my adventures in Pi Hope. 08:25.000 --> 08:29.160 I hope you guys enjoyed this pretty short recounting. 08:29.160 --> 08:35.160 And if you have any feedback or anything like that, I will have some contact information 08:35.160 --> 08:37.040 in the show notes. 08:37.040 --> 08:42.280 And I'll also have the original article that I wrote in the show notes as well. 08:42.280 --> 08:49.600 Thank you guys for listening and make sure you support hacker public radio, contribute yourself. 08:49.600 --> 08:54.520 And more importantly, just enjoy the content that it releases. 08:54.520 --> 09:00.400 Thank you guys for listening. 09:00.400 --> 09:05.480 You have been listening to hacker public radio at hacker public radio.org. 09:05.480 --> 09:09.520 Today's show was contributed by a HBR listening like yourself. 09:09.520 --> 09:15.880 If you ever thought of recording podcast, click on our contributally to find out how easy it 09:15.880 --> 09:16.880 means. 09:16.880 --> 09:22.560 Hosting for HBR has been kindly provided by an onsthost.com. 09:22.800 --> 09:25.580 Internet archive and our sing.net. 09:25.580 --> 09:30.480 On this advice stated, today's show is released on our Creative Commons. 09:30.480 --> 09:34.120 Attribution for.0. International license.